Nested Blockchain System

ABSTRACT

Described in detail herein is a nested blockchain system. The nested blockchain system can include distributed nodes in a network. A node is configured to generate a master cryptographically verifiable distributed ledger represented by a sequence of blocks. The node spawns a first sub cryptographically verifiable ledger represented by a first genesis block containing a hash value referencing the first block generated in the master cryptographically verifiable ledger, in response to a first event. The node purges the first sub cryptographically verifiable ledger, in response to a second event.

RELATED APPLICATIONS

This application claims priority to and the benefit of U.S. ProvisionalApplication No. 62/676,077, filed on May 24, 2018, the content of whichis incorporated by reference herein in its entirety.

BACKGROUND

Large distributed systems can encounter multiple different types of datavalues. Storing the data without converting the data values can causeerrors.

BRIEF DESCRIPTION OF THE FIGURES

Illustrative embodiments are shown by way of example in the accompanyingfigures and should not be considered as a limitation of the presentdisclosure. The accompanying figures, which are incorporated in andconstitute a part of this specification, illustrate one or moreembodiments of the invention and, together with the description, help toexplain the invention. In the figures:

FIGS. 1A-1C are a block diagram illustrating components and multipleblockchains in accordance with an exemplary embodiment;

FIG. 2A is a block diagram illustrating components of a multi-varianttracking system in accordance with an exemplary embodiment;

FIG. 2B is a block diagram illustrating components of an exceptionhandling system in accordance with an exemplary embodiment;

FIG. 2C is a block diagram illustrating components of a multi-varianttracking system in accordance with an exemplary embodiment;

FIGS. 3A-F is a block diagram illustrating components of an inventoryblockchain in accordance with an exemplary embodiment;

FIGS. 4A-D is a block diagram illustrating components of a treasuryblockchain in accordance with an exemplary embodiment;

FIG. 5 is a block diagram illustrating components of a multipleblockchain system in accordance with an exemplary embodiment;

FIG. 6 illustrates an exemplary network diagram of the exceptionhandling system in accordance with an exemplary embodiment;

FIG. 7 depicts an illustration of blocks as configured in accordancewith an exemplary embodiment;

FIG. 8 depicts an illustration of transactions configured in accordancewith an exemplary embodiment;

FIG. 9 depicts a system diagram configured in accordance with anexemplary embodiment;

FIG. 10 depicts a block diagram of an exemplary computing device inaccordance with an exemplary embodiment; and

FIG. 11 is a flowchart illustrating the process of an exception handlingsystem using blockchain controls.

DETAILED DESCRIPTION

Described in detail herein is a nested blockchain system. The nestedblockchain system can include distributed nodes in a network. A node isconfigured to generate a master cryptographically verifiable distributedledger represented by a sequence of blocks. Each block contains one ormore transactions records and each subsequent block containing a hashvalue associated with the previous block. The node generates a firstblock in the master cryptographically verifiable ledger for a firstevent in response to receipt of the first event from a third partysystem. The node executes code included in an associated block of themaster cryptographically verifiable ledger to verify that the firstevent corresponds with a first set of one or more conditions. Inresponse to verification of the first event, the node spawns a first subcryptographically verifiable ledger represented by a first genesis blockcontaining a hash value referencing the first block generated in themaster cryptographically verifiable ledger. The node generates a secondblock in the first sub cryptographically verifiable ledger for a secondevent in response to receipt of a second event from the third partysystem. The node executes code included in the first genesis block toverify that the second event corresponds with a second set of one ormore conditions. In response to the verification of the second event,the node purges the first sub cryptographically verifiable ledger.

The one or more of the nodes are programmed to receive a third event.The one or more of the nodes are programmed to generate a third block inthe master cryptographically verifiable ledger containing transactionrecords of the third event, execute code included in the third block toverify the third event corresponds with a third set of one or moreconditions, and in response to verification of the third event, spawn asecond sub cryptographically verifiable ledger represented by a secondgenesis block containing a hash value associated with the third blockgenerated in the master cryptographically verifiable ledger, associatedwith the third event. The one or more of the nodes is programmed toreceive a fourth event. The one or more of the nodes are programmed togenerate a fourth block in the second sub cryptographically verifiableledger containing transaction records associated with the fourth event.The one or more of the nodes are programmed to purge the second subcryptographically verifiable ledger after a specified amount of timeafter receiving the fourth event.

The first event is associated with the request of a delivery of aphysical object, and the second event is associated with the completionof the delivery of the physical object. The one or more transactionrecords include one or more of a quantity of the at least one physicalobject, a name of the at least one physical object, a type of the atleast one physical object and a size of the at least one physicalobject. The third party system is one or more of a: mobile device, aterminal or a computing device. The terminal is disposed in a facility.

FIGS. 1A-1C are block diagrams illustrating a dataflow while usingmultiple blockchains in accordance with an exemplary embodiment. Withreference to FIG. 1A a blockchain system 100 can include multipleblockchains. The blockchains can store data for different types of dataassociated with a single event. In operation 101, an event can occur ata facility or in a remote location. In operation 102, the blockchainsystem 100 can decompose the event into the different component parts.In operation 106, the blockchain system 100 can determine how eachdomain is affected by the component parts of the event, in response tooperation 104, in which the blockchain system 100 can import componentdictionary/business rules to determine how each component is affected bythe event.

As a non-limiting example, the blockchain system 100 can include acash-on-hand domain, inventory domain, customer identification domain, Ntype information domain, customer/vendor identification domain (thecustomer/vendor identification domain can be external to the blockchainsystem 100), and a profit & loss (P&L) domain. In operations 108-110,the blockchain system 100 can transmit particular data associated witheach domain affected by the event to the cash-on-hand domain, inventorydomain, customer identification domain, N type information domain,customer/vendor identification domain, and/or the profit & loss (P&L)domain, respectively. Each domain can be associated to a respectiveblockchain. Each domain can instruct the respective blockchain togenerate a new block in the cryptographically verifiable ledgerincluding the data affected by the event for the respective domain. Asan example, the cash-on-hand domain can be associated with acash-on-hand blockchain; the inventory domain can be associated with aninventory blockchain; customer identification domain can be associatedwith a customer blockchain, N type information domain can be associatedwith an N blockchain, customer/vendor identification domain can beassociated with a P&L blockchain specific for customers and vendors, andthe profit & loss (P&L) domain can be associated with a P&L blockchain.In operations 120-130, the particular data associated with each domainaffected by the event transmitted to each respective domain can berespectively stored in the corresponding blockchain; data particular tothe cash-on-hand domain can be stored in the cash-on-hand blockchain,data particular to the inventory domain can be stored in the inventoryblockchain, data particular to the customer identification domain can bestored in the customer blockchain, data particular to the N typeinformation domain can be stored in the N type blockchain, dataparticular to the customer/vendor identification domain can be stored inthe individual blockchains specific for customers and/or vendors, anddata particular to the P&L domain can be stored in the P&L blockchain.

With reference to FIG. 1B, in operations 132-140, the blockchain system100 can distribute the respective blockchain ledgers to peers computingdevices in a distributed network. For example, peers can include one ormore of: different facilities, regional data centers, and corporate datacenters. The blockchain ledgers can include the particular dataassociated with each domain affected by the event. In operation 142,third party systems such as vendors can use Application ProgramInterfaces (APIs) to mine the received blockchain ledger. In operation144, systems internal to the blockchain system 100 can mine therespective blockchain ledgers. In operation 146, the particular dataassociated with each domain affected by the event, mined by systemsinternal to the blockchain system 100 can be committed to a relationaldatabase associated with the respective domain.

With reference to FIG. 1C, a blockchain system 100 can include a masterblockchain and sub-blockchains (i.e., blockchains associated with theindividual domains). In operation 152, a data associated with the eventcan be stored in a master blockchain. In operation 154, the masterblockchain can be polled for new data. In operation 156, the data fromthe event can be from master blockchain and disseminated to thesub-blockchains.

FIG. 2A is a block diagram illustrating components of a multi-varianttracking system 200 in accordance with an exemplary embodiment. Themulti-variant tracking system 200 can include multiple independentlyoperated domains. Each independently operated domain can be associatedwith a cryptographically verifiable ledger represented by a sequence ofblocks. Each block can contain one or more transactions records and eachsubsequent block can contain a hash value associated with the previousblock. The multi-variant tracking system 200 can also include a master(or daily) cryptographically verifiable ledger. In operation 202, themulti-variant tracking system 200 can receive an event. The event caninclude transaction records including first data values of a first type.The multi-variant tracking system 200 can determine data stored in theblocks of the cryptographically verifiable ledgers of the independentlyoperated domains that are affected by the event. The multi-varianttracking system 200 can determine a type of data values associated withother transaction records in each cryptographically verifiable ledgerfor the independently operated domains that are affected by the event.In operation 203, the multi-variant tracking system 200 can convert thefirst data value of the first type to a corresponding change in a datavalue of a different type of data value associated with transactionrecords in each cryptographically verifiable ledger for each of theindependently operated domains that are affected by the event. Inoperation 204, additional new blocks containing transaction recordsassociated with the change of the different type of data value can begenerated in each cryptographically verifiable ledger associatedindependently operated domains that are affected by the event. Inoperation 206, a new block including data of the original type of datavalues included in the event can be generated in the mastercryptographically verifiable ledger.

In one embodiment, in operation 208, the multi-variant tracking system200 can receive an event. The event can include first data values of afirst type. The multi-variant tracking system can determine data storedin the cryptographically verifiable ledgers of the independentlyoperated domains that are affected by the event. The multi-varianttracking system 200 can determine a type of data value associated withother transaction records in each cryptographically verifiable ledgerfor the independently operated domains that are affected by the event.In operation 209, the multi-variant tracking system 200 can convert thefirst data value of the first type to a corresponding change in a datavalue of a different type of data value associated with transactionrecords in each cryptographically verifiable ledger for each of theindependently operated domains that are affected by the event. Themulti-variant tracking system 200 can determine if a specific data valueis dependent on a change in data values in one or more differentcryptographically verifiable ledgers. The multi-variant tracking system200 can derive the change in the specific data value from the change indata values in the one or more different cryptographically verifiableledgers. In operation 210, additional new blocks containing transactionrecords associated with the change of the different type of data valuecan be generated in each cryptographically verifiable ledger associatedindependently operated domains, affected by the event. In operation 212,a new block including data of the original type of data values includedin the event can be generated in the master cryptographically verifiableledger.

FIG. 2B is a block diagram illustrating components of an exceptionhandling system 220 in accordance with an exemplary embodiment. Theexception handling system can include multiple independently operateddomains. Each independently operated domain can be associated with adistinct cryptographically verifiable ledger represented by a sequenceof blocks. Each block can contain one or more transactions records andeach subsequent block contain a hash value associated with the previousblock. In operation 222, the exception handling system 220 can receivean event including transaction records. In operation 224, a firstindependently operated domain can generate a new block in thecryptographically verifiable ledger associated with the independentlyoperated domain. The new block can store the transaction recordsassociated with the event. In operation 226, the exception handlingsystem 220 can receive an alert of the creation of the new block storingthe transaction records of the event in the cryptographically verifiableledger of the first independently operated domain. The exceptionhandling system 220 can initiate a smart contract based on thetransaction records stored in the cryptographically verifiable ledger ofthe first independently operated domain. As an example, the smartcontract can include a triggering event based on the transaction recordsof the event. The triggering event can be a specified threshold.

In operation 228, the exception handling system 220 can determinewhether the threshold (i.e., triggering event) has been satisfied. Ifnot, the process waits for the next event. In response the determiningthe threshold has been satisfied, the exception handling system 220 canidentify an error in one or more of the independently operated domainsthat are different than the first independently operated domain. Inoperation 230, a message indicating the error can be transmitted to theone or more independently operated domains. In operation 232, theexception handling system 220 can store the error in a relationaldatabase. In operation 234, the exception handling system 220 cantrigger creation of additional new blocks in each cryptographicallyverifiable ledger associated with the one or more of the plurality ofindependently operated domains. The additional new blocks can containinformation associated with the error. The exception handling system cantrigger an action to resolve the error for each of the one or moreindependently operated domains.

FIG. 2C is a block diagram illustrating components of a nestedblockchain system 250 in accordance with an exemplary embodiment. Theexception handling system can include multiple distributed nodes in anetwork. In operation 252, an event can be transmitted to the nestedblockchain system 250 from third party system. In operation 254, thenested handling system 250 can generate a first block in the mastercryptographically verifiable ledger for a first event in response toreceipt of the first event from a third party system. In operation 256,the nested blockchain system 250 can initiate a smart contract byexecuting code included in an associated block of the mastercryptographically verifiable ledger to verify that the first eventcorresponds with a first set of one or more conditions. In operation258, the nested blockchain system 250 can determine whether a subcryptographically verifiable ledger associated with the first eventcurrently exists. In operation 260, in response to determining the subcryptographically verifiable ledger already exists, the nestedblockchain system 250 can generate a genesis block containing a hashvalue referencing the new block generated in the mastercryptographically verifiable ledger. In operation 262, in response todetermining the sub cryptographically verifiable ledger does not exist,the nested blockchain system 250 can spawn a sub cryptographicallyverifiable ledger represented generate genesis block containing a hashvalue referencing the new block generated in the mastercryptographically verifiable ledger.

In operation 270, an event can be transmitted to the nested blockchainsystem 250 from third party system. In operation 272, the nestedhandling system 250 can generate a first block in the mastercryptographically verifiable ledger for a first event in response toreceipt of the first event from a third party system. In operation 274,the nested blockchain system 250 can initiate a smart contract byexecuting code included in an associated block of the mastercryptographically verifiable ledger to verify that the event correspondswith one or more conditions. In operation 276, the nested blockchainsystem 250 can determine whether a sub cryptographically verifiableledger is no longer needed based on the event corresponding to one ormore conditions. In operation 278, in response to determining the subcryptographically verifiable ledger is no longer needed, the subcryptographically verifiable ledger is purged, otherwise it ismaintained.

FIGS. 3A-F is a block diagram illustrating components inventoryblockchain 300 in accordance with an exemplary embodiment. Withreference to FIG. 3A, the inventory blockchain 300 can include a masterblockchain, an n area blockchain, facility level inventory blockchain,detail level blockchain and external output. The inventory blockchain300 can include multiple sub-blockchains. Each sub-blockchain can beassociated with a parent blockchain. A sub-blockchain may be associatedwith a further sub-blockchain. The master blockchain and eachsub-blockchain can include cryptographically verifiable ledgers that arerepresented by a sequence of blocks. Each block can contain one or moretransactions records and each subsequent block can contain a hash valueassociated with the previous block. The first block in thecryptographically verifiable ledger of a sub-blockchain can include ahash value associated with a block in cryptographically verifiableledger of its parent blockchain.

In operation 302, the master blockchain can receive an event includingtransaction records. The master blockchain can trigger multipletransactions based on the received event. In operation 304, thetransactions can be transmitted to children (i.e., sub-blockchains).Alternatively, or in addition, in operation 306, the master blockchaincan transmit the transactions to the facility level blockchain. Thefacility level blockchain can include multiple sub-blockchains. Thesub-blockchains can have parent/child and/or sibling relationships. Inoperation 308, the transactions can be transmitted to the detail levelblockchain. The detail level blockchain can be a sub-blockchain whichcan reside independently and interact with parent blockchains. As anon-limiting example, the inventory blockchain 300 can be implemented ina retail store environment.

With reference to FIGS. 3B-3D concurrently, the facility of the facilitylevel blockchain 320 can be retail store. The facility level blockchaincan include a cryptographically verifiable ledger represented by asequence of blocks. Each block can contain one or more transactionsrecords and each subsequent block can contain a hash value associatedwith the previous block. In operation 322, the facility level blockchain320 can receive an event based on a Point Of Sale (POS) transaction inthe retail store. In operation 324, a new sub-blockchain can be spawnedbased on the event. The first block of the sub-blockchain can begenerated and can include the POS transaction records. In operation 362,the sub-blockchain can retrieve its parent blockchain hash value andstore the hash value in the first block. In operation 330, the status ofthe new sub-blockchain can be updated. In operation 326, the facilitylevel blockchain 320 can receive a request to purge the newsub-blockchain. In operation 362, the hash value of the parentblockchain of the new sub-blockchain can be retrieved and the newsub-blockchain can be purged. In operation 330, the chain status isupdated to reflect the purged new sub-blockchain.

In operation 328, the facility level blockchain 320 can receive a newevent corresponding to a truck arriving with item inventory. Thefacility level blockchain 320 can generate new block in thecryptographically verifiable ledger including the transaction records ofa truck arriving with item inventory. In operation 332, the status ofthe truck can be updated. In operation 334, the purchase order detailsassociated with the item inventory in the truck can be updated. Inresponse to updating the truck status, smart contract functions 336 canbe triggered to execute. In particular, in operation 340, the receivedtruck smart contract can be triggered to execute based on the truckarriving at the retail store with item inventory. The received trucksmart contract can update the status of the truck which was anticipatedto arrive. A new block in the facility level blockchain 320 can begenerated. The new block can include the status of the arrived truck. Inoperation 342, in response to the received truck smart contract beingtriggered to execute, a validate purchase order smart contract can betriggered. The validate purchase order smart contract can validate thepurchase orders of the items delivered in the truck. A new block in thefacility level blockchain 320 can be generated. The new block caninclude the validation of the purchase orders. In operation 344, inresponse to the validate purchase order smart contract being triggeredto execute, the modify item inventory smart contract can be triggered toexecute. The modify item inventory smart contract can modify the iteminventory based on the new item inventory delivered. A new block in thefacility level blockchain 320 can be generated. The new block caninclude the new item inventory. In response to the modify inventory itemsmart contract being triggered to execute, in operation 364, thetransaction can be logged in a relational database. In response to themodify inventory item smart contract being triggered to execute, inoperation 370, a peer/sibling blockchain associated with the iteminventory can be updated.

Additional smart contracts can include validating the forecast smartcontract 338, backhaul/return item smart contract 346, close myselfsmart contract 348, charge labor smart contract 350, create child (i.e.,sub-blockchain) smart contract 352, and request a child to close smartcontract 354. In response to triggering the create child and/or requesta child to close smart contract, in operation 366, the triggered actioncan be logged in a relational database. In response to triggering thebackhaul/return item smart contract, in operation 368, abackhaul/transportation of the returned item can be requested. Inresponse to the charge labor smart contract being triggered, inoperation 370, a peer/sibling blockchain associated with the laborinformation is updated.

In response to the truck status being updated, in operation 356,time-based smart contracts can be triggered to execute. A validation ofthe balance against a threshold smart contract can be triggered toexecute. In operation 320, n Operational Business Rules can triggertime-based smart contracts, such as a validation of business rules smartcontract, to execute. An additional time-based smart contract, anoperational audit smart contract, can also be triggered to execute. Inresponse to the validation of business rules smart contract beingtriggered to execute, in operation 372, the sub-blockchain businessrules can be validated. In operation 374, real-time attributesassociated with the various blockchains can be queried. In operation376, a traditional relational database can store all the information inthe various blockchains.

With reference to FIG. 3E-3F concurrently, the detail level blockchain377 can include master and sub-blockchains, each blockchain including acryptographically verifiable ledger represented by a sequence of blocks.Each block can contain one or more transactions records and eachsubsequent block can contain a hash value associated with the previousblock. In operation 378, the detail level blockchain 377 can receive anevent based on a transaction. In operation 379, a new sub-blockchain canbe spawned based on the event. The first block of the sub-blockchain canbe generated and can include the transaction records. In operation 413,the sub-blockchain can retrieve its parent blockchain hash value andstore the hash value in the first block. In operation 483, the status ofthe new sub-blockchain can be updated. In operation 380, the detaillevel blockchain 377 can receive a request to purge the newsub-blockchain. In operation 413, the hash value of the parentblockchain of the new sub-blockchain can be retrieved. The hash value ofthe parent blockchain can be used for authorization to purge the newsub-blockchain. In operation 383, the chain status is updated to reflectthe purged new sub-blockchain.

In operation 381, the detail level blockchain 377 can receive a requestfrom a peer such as a transportation blockchain. For example, a truckcan arrive at the retail store with new item inventory. In response toreceiving a request from the transportation blockchain, the smartcontracts 391 can be triggered to execute. In operation 394, theinventory added smart contract can be triggered to execute. Theinventory added smart contract can be executed to add the inventoryadded by the new items being delivered to the retail store. In operation382, the detail level blockchain 377 can receive a request from a peersuch as a POS blockchain indicating sold items at the retail store. Inoperation 393, the inventory subtract smart contract can be triggered toexecute. The inventory subtract contract can be executed to subtract theitems sold from the inventory. In response to executing the inventoryadd and inventory subtract smart contracts, in operation 395, the adjustbalance smart contract can be triggered to execute. The adjust balancesmart contract can be executed to adjust the items from the backroom tothe shelving units on the sales floor of the retail store. In responseto executing the adjust balance smart contract, in operation 408, thetransaction can be logged in a relational database.

Additional smart contracts can be triggered to execute, such asvalidating a forecast smart contract 392, a close myself smart contract396, a request restock smart contract 397, a charge labor smart contract399, and a create order smart contract 398. In response to executing thecharge labor smart contract and the create smart order contract 396, thedetail level blockchain 377 can request transactions from peer/siblingblockchains.

In operation 403, a time-based smart contract, such as a validatebalance against threshold smart contract, can be triggered to execute.In response to executing the validate balance against threshold smartcontract, in operation 400, the check in-stock smart contract can betriggered to execute. The check instock smart contract can be executedto verify products are in stock. In operation 406, a time-based smartcontract, such as an inventory close smart contract, can be triggered toexecute. In response to executing the inventory close smart contract, inoperation 401, the accounting functions smart contract can be triggeredto execute. The check in-stock smart contract can be executed to verifyproducts are in stock. In operation 405, the time-based smart contract,operations audit, can be triggered to execute.

In operation 390, n Operational Business Rules can call the time-basedsmart contracts, such as a validation of business rules smart contract.In operation 407, the validation of business rules smart contract can betriggered to execute. In operation 410, in response to the validation ofbusiness rules smart contract being triggered to execute, thesub-blockchain business rules can be validated.

In operation 411, the blockchains can be queried to retrieve attributesassociated with the blockchains. The blockchains can include one or moreof, item inventory (shelf) 384, item inventory (backroom) 385, iteminventory (riser) 386, modular locations 387, modular capacity 388, andpresentation quantity 389. In operation 412, a relational database canbe generated to store the information in the detail level blockchain377.

FIGS. 4A-D is a block diagram illustrating components treasuryblockchain in accordance with an exemplary embodiment. The treasuryblockchain can include multiple sub-blockchains. Each sub-blockchain canbe associated with a parent blockchain. A sub-blockchain may beassociated to a further sub-blockchain. A master blockchain and eachsub-blockchain include cryptographically verifiable ledgers that arerepresented by a sequence of blocks. Each block can contain one or moretransactions records and each subsequent block can contain a hash valueassociated with the previous block. The first block in thecryptographically verifiable ledger of a sub-blockchain can include ahash value associated with a block in cryptographically verifiableledger of its parent blockchain. As a non-limiting example, the treasuryblockchain can be implemented in a retail store.

With reference to FIGS. 4A-4B concurrently, the treasury blockchain caninclude a facility level blockchain 420. The facility associated withthe facility level blockchain 420 can be retail store. The facilitylevel blockchain can include a cryptographically verifiable ledgerrepresented by a sequence of blocks. Each block can contain one or moretransactions records and each subsequent block can contain a hash valueassociated with the previous block. In operation 422, the facility levelblockchain 420 can receive an event based on a POS transaction. Inoperation 423, a new sub-blockchain can be spawned based on the event.The first block of the sub-blockchain can be generated and can includethe transaction records. In operation 448, the sub-blockchain canretrieve its parent blockchain hash value and store the hash value inthe first block. In operation 426, the status of the new sub-blockchaincan be updated. In operation 424, the facility level blockchain 420 canreceive a request to purge the new sub-blockchain. In operation 448, thehash value of the parent blockchain of the new sub-blockchain can beretrieved and the new sub-blockchain can be purged. In operation 426,the chain status is updated to reflect the purged new sub-blockchain.

In operation 425, the facility level blockchain 420 can receive arequest for a transaction for a carrier visit. In response to receivinga request for a transaction for a carrier visit, the smart contracts 433can be triggered to execute. In operation 435, the execute transferbetween accounts smart contract can be triggered to execute. The executetransfer between accounts smart contract can be executed to transfercurrency between accounts. In response to executing the execute transferbetween accounts smart contract, in operation 442, validate transferbetween accounts smart contract can be triggered to execute. In responseto executing, the validate transfer between accounts smart contract, inoperation 436 the adjust balance smart contract can be triggered toexecute. In response to executing the adjust balance smart contract, inoperation 449, the transaction can be logged in a relational database.

Additional smart contracts can be triggered to execute, such asvalidating a forecast smart contract 434, close myself smart contract438, create child smart contract 439 and request child to close smartcontract 440. In response to executing the create child smart contractand request child to close smart contract, in operation 450, the childaction is logged in a relational database.

In operation 443, a time-based smart contract, validate balance againstthreshold smart contract, can be triggered to execute. In response toexecuting the validate balance against threshold smart contract, inoperation 436, the check balance smart contract can be triggered toexecute. In operation 447, a time-based smart contract, close bookssmart contract, can be triggered to execute. In response to executingthe inventory close smart contract, in operation 441, the accountingfunctions smart contract can be triggered to execute. In operation 445,the time-based smart contract, operations audit, can be triggered toexecute.

In operation 432, n Operational Business Rules can call the time-basedsmart contracts, such as a validation of business rules smart contract.In operation 446, the validation of business rules smart contract can betriggered to execute. In operation 451, in response to the validation ofbusiness rules smart contract being triggered to execute, thesub-blockchain business rules can be validated.

In operation 452, the blockchains can be queried to retrieve attributesassociated with the blockchains. The blockchains can include one or moreof a register note/coin balance by denomination 427, a vault note/coinbalance by denomination 428, a recycler note/coin balance bydenomination 429, an in-transit note/coin balance by denomination 430,and a balance thresholds 431. In operation 453, a traditional relationaldatabase can be generated to store the information stored in thefacility level blockchain 420.

With reference to FIGS. 4C-4D concurrently, the treasury blockchain caninclude a detail level blockchain 454. The detail level blockchain 454can include master and sub-blockchains, and each blockchain can includea cryptographically verifiable ledger represented by a sequence ofblocks. Each block can contain one or more transactions records and eachsubsequent block can contain a hash value associated with the previousblock. In operation 455, the detail level blockchain 454 can receive anevent based on a transaction. In operation 456, a new sub-blockchain canbe spawned based on the event. The first block of the sub-blockchain canbe generated and can include the transaction records. In operation 482,the sub-blockchain can retrieve its parent blockchain hash value andstore the hash value in the first block. In operation 459, the status ofthe new sub-blockchain can be updated. In operation 457, the detaillevel blockchain 454 can receive a request to purge the newsub-blockchain. In operation 482, the hash value of the parentblockchain of the new sub-blockchain can be retrieved and the newsub-blockchain can be purged. In operation 426, the chain status isupdated to reflect the purged new sub-blockchain.

In operation 458, the detail level blockchain 454 can receive a requestfor adding/subtracting from the balance from a parent blockchain. Inresponse to receiving a request adding/subtracting from the balance, thesmart contracts 466 can be triggered to execute. In operation 468, thein-cash smart contract can be triggered to execute. In operation 469,the out-cash contract can be triggered to execute. In response toexecuting the in or out cash smart contracts, in operation 470, theadjust balance smart contract can be triggered to execute. In responseto executing the adjust balance smart contract, in operation 482, thetransaction can be logged in a relational database.

Additional smart contracts can be triggered to execute such asvalidating a forecast smart contract 467, a close myself smart contract471, and a request funds smart contract 472. In response to executingthe request funds smart contract smart contract, in operation 484, arequest for the transaction can be made to the parent blockchain.

In operation 477, a time-based smart contract, a validate balanceagainst threshold smart contract, can be triggered to execute. Inresponse to executing the validate balance against threshold smartcontract, in operation 474, the check balance smart contract can betriggered to execute. In operation 481, a time-based smart contract,close books smart contract can be triggered to execute. In response toexecuting the inventory close smart contract, in operation 475, theaccounting functions smart contract can be triggered to execute. Inoperation 479, the time-based smart contract, operations audit, can betriggered to execute.

In operation 465, n Operational Business Rules can call the time-basedsmart contracts, such as a validation of business rules smart contract.In operation 480, the validation of business rules smart contract can betriggered to execute. In operation 485, in response to the validation ofbusiness rules smart contract being triggered to execute, thesub-blockchain business rules can be validated.

In operation 486, the blockchains can be queried to retrieve attributesassociated with the blockchains. The blockchains can include one or moreof a register note/coin balance by denomination 460, a vault note/coinbalance by denomination 461, a recycler note/coin balance bydenomination 462, an in-transit note/coin balance by denomination 463,and a balance thresholds 464. In operation 487, a traditional relationaldatabase can be generated to store the information in the detail levelblockchain 454.

FIG. 5 is a block diagram illustrating components of a multipleblockchain system in accordance with an exemplary embodiment. Themultiple blockchain system 500 can include multiple layers ofblockchains. Each blockchain can include a cryptographically verifiableledger represented by a sequence of blocks. Each block can contain oneor more transactions records and each subsequent block can contain ahash value associated with the previous block. Each blockchain can havea parent/child and/or sibling relationship with another blockchain. Thefirst block in the child blockchain can include a hash value to a blockin the parent blockchain. The parent blockchains can spawn and purgechildren blockchains.

The multiple blockchain system 500 can include a master blockchain 502and sub-blockchains 504-524. The master blockchain 502 can be includedin a central computing system (not shown in FIG. 5) and thesub-blockchains 504-524 can be included in sub-computing systems (notshown in FIG. 5). The central computing system and the sub-computingsystems can include one or more servers, one or more computing devices,one or more processing device, and/or one or more nodes in a distributednetwork, to control the operations of the master and sub-blockchains.The master blockchain 502 may not have an associated parent blockchain.The multiple blockchain system 500 can further include sub-blockchains504-508. The master blockchain and sub-blockchains 504-508 can have adirect parent-child relationship. The master blockchain 504-508 canspawn the sub-blockchains 504-508 in response to receiving an event. Themultiple blockchain system 500 can have further sub-blockchains 510-512with a direct parent-child relationship with sub-blockchain 504. Themultiple blockchain system 500 can have further sub-blockchains 514-516with a direct parent-child relationship with sub-blockchain 512. Themultiple blockchain system 500 can have further sub-blockchains 518-520with a direct parent-child relationship with sub-blockchain 516. Themultiple blockchain system 500 can have further sub-blockchains 522-524with a direct parent-child relationship with sub-blockchain 518.

As described above, the master blockchain can receive an event includingtransaction records. The central computing system can identify one ormore of the sub-blockchains 504-508 affected by the event. The centralcomputing system can transmit the event including the transactionrecords to one or more of the sub-computing systems including thesub-blockchains 504-508 affected by the event. In one embodiment, thecentral computing system can spawn the one of the sub-blockchains504-508 in the sub-computing systems, prior to transmitting the eventand the transaction records. As an example, the central computing systemcan transmit the event and transaction records to the sub-computingsystem and trigger a new block to be generated in the cryptographicallyverifiable ledger associated with the sub-blockchain 504. The new blockcan include the transaction records from the event.

The sub-computing system of the sub-blockchain 504 can identifysub-computing systems of the sub-blockchains 510-512 are affected by theevent. The sub-computing system of the sub-blockchain 504 can transmitthe event and transaction records to the sub-computing systems of thesub-blockchain 510 and sub-blockchain 512 and trigger a new block to begenerated in the cryptographically verifiable ledger associated with thesub-blockchain 510 and sub-blockchain 512. The new block can include thetransaction records from the event.

The sub-computing system of the sub-blockchain 512 can identifysub-computing systems of the sub-blockchains 514-516 are affected by theevent. The sub-computing system of the sub-blockchain 512 can transmitthe event and transaction records to the sub-computing systems of thesub-blockchain 514 and sub-blockchain 516 and trigger a new block to begenerated in the cryptographically verifiable ledger associated with thesub-blockchain 514 and sub-blockchain 516. The new block can include thetransaction records from the event.

The sub-computing system of the sub-blockchain 516 can identifysub-computing systems of the sub-blockchains 518-520 are affected by theevent. The sub-computing system of the sub-blockchain 516 can transmitthe event and transaction records to the sub-computing systems of thesub-blockchain 518 and sub-blockchain 520 and trigger a new block to begenerated in the cryptographically verifiable ledger associated with thesub-blockchain 518 and sub-blockchain 520. The new block can include thetransaction records from the event.

The sub-computing system of the sub-blockchain 518 can identifysub-computing systems of the sub-blockchains 522-524 are affected by theevent. The sub-computing system of the sub-blockchain 518 can transmitthe event and transaction records to the sub-computing systems of thesub-blockchain 522 and sub-blockchain 524 and trigger a new block to begenerated in the cryptographically verifiable ledger associated with thesub-blockchain 522 and sub-blockchain 524. The new block can include thetransaction records from the event.

Each blockchain can store different types of data values. The parentblockchains can identify the type of data values stored in the childblockchains. The parent blockchains can convert the type of data valuestored in the parent blockchain to a type of data value stored in thechild blockchain for the transaction records associated with the event.The types of data values can be one or more of, monetary currency, laborcosts, inventory costs, and/or temporal costs.

As described above, the parent blockchain can purge a child blockchainbased on an event satisfying threshold requirements (i.e., as set forthin a smart contract). As an example, the sub-blockchain 512 can purgeand/or archive sub-blockchain 514 based on a received event.

FIG. 6 illustrates an exemplary network diagram of an embodiment of thenested blockchain system 250 in accordance with an exemplary embodiment.In the present example embodiment, the nested blockchain system 250 caninclude one or more data storage devices 605, one or more centralcomputing systems 602, one or more sub nodes 642, and one or more thirdparty systems 660. The central computing system 602 can be incommunication with the data storage devices 605, the independentlyoperated domains 640 and third party systems 660, via a communicationsnetwork 615. The central computing system 602 can execute at least oneinstance of a decision engine 606. The decision engine 606 can be anapplication configured to implement the nested blockchain system 250,described herein. The central computing system can include a node 640.The node 640 can store a copy of a master blockchain record and/or ashared ledger storing data associated events of data. The masterblockchain can be embodied as a master cryptographically verifiableledger represented by a sequence of blocks, each block containing one ormore transactions records and each subsequent block containing a hashvalue associated with the previous block.

The sub node 642 can store a copy of a sub blockchain record and/or ashared ledger storing data associated events of data. The blockchain canbe embodied as sub cryptographically verifiable ledger represented by asequence of blocks, each block containing one or more transactionsrecords and each subsequent block containing a hash value associatedwith the previous block.

The master cryptographically verifiable ledger and the subcryptographically verifiable ledgers can have a parent-childrelationship. The master cryptographically verifiable ledgers cancontrol the addition and subtraction of blocks in the subcryptographically verifiable ledgers. Additionally, the mastercryptographically verifiable ledger can purge and/or spawn multiple subcryptographically verifiable ledgers. It also can be appreciated thatsub cryptographically verifiable ledgers can spawn further subcryptographically verifiable ledgers. The sub cryptographicallyverifiable ledgers can have parent-child relationships with the furthersub cryptographically verifiable ledgers. The sub cryptographicallyverifiable ledgers can control the addition and subtraction of blocks inthe further sub cryptographically verifiable ledgers. Additionally thesub cryptographically verifiable ledgers can purge the further subcryptographically verifiable ledgers.

In an example embodiment, one or more portions of the communicationsnetwork 615 can be an ad hoc network, an intranet, an extranet, avirtual private network (VPN), a local area network (LAN), a wirelessLAN (WLAN), a wide area network (WAN), a wireless wide area network(WWAN), a metropolitan area network (MAN), a portion of the Internet, aportion of the Public Switched Telephone Network (PSTN), a cellulartelephone network, a wireless network, a WiFi network, a WiMax network,another type of network, or a combination of two or more such networks.

The central computing system 602 includes one or more computers orprocessors configured to communicate with the data storage devices 605,and the sub nodes 642. The data storage devices 605 can storeinformation/data, as described herein. For example, the data storagedevices 605 can include an events database 630, and a physical objectsdatabase 635. The events database 630 can be embodied relationaldatabase configured to store information associated with event. As anon-limiting example, the event database 630 can store transactionrecords associated with physical objects such as invoices, purchaseorders, inventory records, sales/returns records, vendor orders, claims,shipping orders, and/or receiving orders. The physical objects database635 can store information associated with physical objects disposed at afacility. The data storage devices 605 and the central computing system602 can be located at one or more geographically distributed locationsfrom each other. Alternatively, the data storage devices 605 can beincluded within the central computing system 602.

In an exemplary embodiment, the central computing system 602 can receivea first event including transaction records associated with a physicalobject, from a third party system 660. The central computing system 602can execute the decision engine 606 in response to receiving the firstevent. The decision engine 606 can query the physical objects database635 to verify the first event. The decision engine 606 can instruct thenode 640 to generate a block in the master cryptographically verifiableledger for a first event in response to receipt of the first event fromthe third party system. The node 640 can generate the block includingrecords associated with the first event in the master cryptographicallyverifiable ledger.

The decision engine 606 can instruct the node 640 to execute code storedin the master cryptographically verifiable ledger to verify that thefirst event corresponds with a first set of one or more conditions. Asan example, the conditions can be associated with the date and/or timeof the event, the location the event occurred, the type of event and/orother details related to the event. The code can be associated with theinitiation of a smart contract. In response to verification of the firstevent, the decision engine 606 can instruct the node 606 to spawn afirst sub cryptographically verifiable ledger represented by a firstgenesis block containing a hash value referencing the block generated inthe master cryptographically verifiable ledger. The node 640 cangenerate the first sub cryptographically verifiable ledger including ablock including a hash value of the block created in the mastercryptographically verifiable ledger, including the transaction recordsof the first event. The block generated in the first subcryptographically verifiable ledger can also include the transactionrecords of the event. The first sub cryptographically verifiable ledgercan be represented by the sub node 642.

The central computing system 602 can receive a second event from thethird party system 660. The decision engine 606 can query the physicalobjects database 635 to verify the second event is associated to thefirst event. The decision engine 606 can trigger the generation of thenew block in the first sub cryptographically verifiable ledgerassociated with the second event. The node 640 can generate a new blockin the first sub cryptographically verifiable ledger includingtransaction records associated with the second event. The decisionengine 606 can execute code included in the block of the first subcryptographically verifiable ledger containing transaction recordsassociated with the first event, to verify the second event correspondswith one or more conditions. The code can be associated with thecompletion of the smart contract. In response to the verification of thesecond event the decision engine 606 can purge the first subcryptographically verifiable ledger. In one embodiment, the decisionengine 606 can archive the first sub cryptographically verifiableledger.

The central computing system 602 can receive a third event. The decisionengine 606 can query the physical objects database 630 to verify thethird event. The decision engine 606 can trigger the generation a newblock to be generated in the master cryptographically verifiable ledgercontaining transaction records of the third event. The node 640 cangenerate the new block in the master cryptographically verifiable ledgerincluding the transaction records of the third event. The decisionengine 606 can execute code included in the newly generated block toverify the third event corresponds with a third set of one or moreconditions. In response to verification of the third event, the decisionengine 606 can spawn a second sub cryptographically verifiable ledgerrepresented by a genesis block containing a hash value associated withthe newly generated block generated in the master cryptographicallyverifiable ledger, associated with the third event. The sub node 642 canrepresent the second sub cryptographically verifiable ledger.

The central computing system 602 can receive a fourth event. Thedecision engine 606 can query the physical objects database 630 toverify the fourth event. The decision engine 606 can trigger thegeneration a new block to be generated in the second subcryptographically verifiable ledger containing transaction records ofthe fourth event. The sub node 642 can generate the new block in thesecond sub cryptographically verifiable ledger including the transactionrecords of the fourth event. The decision engine 606 can trigger thenode 640 to purge the second sub cryptographically verifiable ledgerafter a specified amount of time after receiving the fourth event.

As an example, the first event can be associated with the request of adelivery of a physical object and the second event can be associatedwith the completion of the delivery of the physical object. Thetransaction records of the first, second, third, or fourth include oneor more of a quantity of the at least one physical object, a name of theat least one physical object, a type of the at least one physical objectand a size of the at least one physical object.

In one embodiment, the third party system 660 is one or more of a:mobile device, a terminal or a computing device. The terminal can be asystem disposed in a facility. Additionally, the decision engine 606 canarchive each received event in the events database 630. As describedabove, the events database 630 can be a relational database.

As a non-limiting example, nested blockchain system 250 can beimplemented as in a retail store and/or e-commerce website. For example,the sub cryptographically verifiable ledgers can be storing andprocessing inventory, sales, purchase orders, or retail store stockrooms. The physical objects can be embodied as products sold at theretail store and/or e-commerce website. The third party system 660 canbe a mobile/computing device executing an application associated withthe retail store/e-commerce website, or a Point of Sale (POS) terminal.

In one example, the first event can be associated with a purchase of aproduct. The decision engine 606 can query the physical objects database635 to verify the purchase. The node 640 can generate the blockincluding transaction records associated with the purchase in the mastercryptographically verifiable ledger. The decision engine 606 caninstruct the node 640 to execute code stored in the mastercryptographically verifiable ledger to verify that the purchase requiresa delivery of the purchased products. In response to verification of thefirst event, the decision engine 606 can instruct the node 640 to spawna first sub cryptographically verifiable ledger represented by a genesisblock containing a hash value referencing the block generated in themaster cryptographically verifiable ledger. The node 640 can generatethe first sub cryptographically verifiable ledger including a blockincluding a hash value of the block created in the mastercryptographically verifiable ledger, including the transaction recordsof the purchase of the product and the initiation of the delivery of theproduct.

The central computing system 602 can receive a second event from thethird party system 660. As an example, the second event can be thecompletion of the delivery of the product. The decision engine 606 canquery the physical objects database 635 to verify the second event isassociated to the first event. The decision engine 606 can trigger thegeneration of the new block in the first sub cryptographicallyverifiable ledger associated with the second event. The node 640 cangenerate a new block in the first sub cryptographically verifiableledger including transaction records associated with the completion ofthe delivery. The decision engine 606 can execute code included in theblock of the first sub cryptographically verifiable ledger containingtransaction records associated with the first event, to verify thesecond event corresponds with one or more conditions. The conditions canbe associated with the completion time, date, and location of thedelivery of the product.

Descriptions of some embodiments of blockchain technology are providedwith reference to FIGS. 7-9 herein. In some embodiments, blockchaintechnology may be utilized for exception handling in a distributedsystem as described herein. One or more of the independently operateddomains as described herein may comprise a node in a distributedblockchain system storing a copy of the blockchain record. Updates tothe blockchain may comprise information associated with eventsassociated with physical objects received by the independently operateddomains, and one or more nodes on the system may be configured toincorporate one or more events into blocks to add to the distributeddatabase.

Distributed database and shared ledger database generally refer tomethods of peer-to-peer record keeping and authentication in whichrecords are kept at multiple nodes in the peer-to-peer network insteadof being kept at a trusted party. However, exemplary embodiments of thepresent disclosure can also utilize a private (trusted) system tomaintain the blockchains. A blockchain may generally refer to adistributed database that maintains a growing and ordered list or chainof records in which each block contains a hash of some or all previousrecords in the chain to secure the record from tampering andunauthorized revision. A hash generally refers to a derivation oforiginal data. In some embodiments, the hash in a block of a blockchainmay comprise a cryptographic hash that is difficult to reverse and/or ahash table. Blocks in a blockchain may further be secured by a systeminvolving one or more of a distributed timestamp server, cryptography,public/private key authentication and encryption, proof standard (e.g.proof-of-work, proof-of-stake, proof-of-space), and/or other security,consensus, and incentive features. In some embodiments, a block in ablockchain may comprise one or more of a data hash of the previousblock, a timestamp, a cryptographic nonce, a proof standard, and a datadescriptor to support the security and/or incentive features of thesystem.

In some embodiments, the exception handling system comprises adistributed timestamp server comprising a plurality of nodes configuredto generate computational proof of record integrity and thechronological order of its use for content, trade, and/or as a currencyof exchange through a peer-to-peer network. In some embodiments, when ablockchain is updated, a node in the distributed timestamp server systemtakes a hash of a block of items to be timestamped and broadcasts thehash to other nodes on the peer-to-peer network. The timestamp in theblock serves to prove that the data existed at the time in order to getinto the hash. In some embodiments, each block includes the previoustimestamp in its hash, forming a chain, with each additional blockreinforcing the ones before it. In some embodiments, the network oftimestamp server nodes performs the following steps to add a block to achain: 1) new activities are broadcasted to all nodes, e.g., resultingfrom in-field authentication of autonomous electronic devices, 2) eachnode collects new activities into a block, 3) each node works on findinga difficult proof-of-work for its block, 4) when a node finds aproof-of-work, it broadcasts the block to all nodes, 5) nodes accept theblock only if activities are authorized, and 6) nodes express theiracceptance of the block by working on creating the next block in thechain, using the hash of the accepted block as the previous hash. Insome embodiments, nodes may be configured to consider the longest chainto be the correct one and work on extending it.

Now referring to FIG. 7, an illustration of a blockchain according toembodiments of the present disclosure is shown. As mentioned in above,with reference to FIG. 6, a blockchain comprises a hash chain or a hashtree in which each block added in the chain contains a hash of theprevious block. In FIG. 7, block 0 700 represents a genesis block of thechain and can be generated in response to an event received associatedwith one or more physical objects. The block 0 700 can includeinformation associated with the event associated with the physicalobjects and a hash key and a timestamp. The information associated withthe event received associated with one or more physical objects caninclude information associated with the physical objects and informationassociated with the event, such as the delivery of the physical object,a quantity of the at least one physical object, name of the at least onephysical object, type of the at least one physical object and size ofthe at least one physical object, and/or transfer of the ownership ofphysical objects. Block 1 710 can be generated in response to averification of the event. The block 1 710 can contain a hash of block 0700. The block 1 710 can include the information associated with theevent and the physical objects. Otherwise, the block 1 710 can includeinformation that an event was not verified. Additional blocks can begenerated as additional requests are received and each block that isgenerated can include a hash of a previous block. For example, block 2720 can be generated in response to a subsequent request and can containa hash of block 1 710, block 3 730 can be generated in response to a yetanother subsequent request and can contain a hash of block 2 720, and soforth. Continuing down the chain, block N contains a hash of block N−1.In some embodiments, the hash may comprise the header of each block.Once a chain is formed, modifying or tampering with a block in the chainwould cause detectable disparities between the blocks. For example, ifblock 1 is modified after being formed, block 1 would no longer matchthe hash of block 1 in block 2. If the hash of block 1 in block 2 isalso modified in an attempt to cover up the change in block 1, block 2would not then match with the hash of block 2 in block 3. In someembodiments, a proof standard (e.g. proof-of-work, proof-of-stake,proof-of-space, etc.) may be required by the system when a block isformed to increase the cost of generating or changing a block that couldbe authenticated by the consensus rules of the distributed system,making the tampering of records stored in a blockchain computationallycostly and essentially impractical. In some embodiments, a blockchainmay comprise a hash chain stored on multiple nodes as a distributeddatabase and/or a shared ledger, such that modifications to any one copyof the chain would be detectable when the system attempts to achieveconsensus prior to adding a new block to the chain. In some embodiments,a block may generally contain any type of data and record. In someembodiments, each block may comprise a plurality of transaction and/oractivity records.

In some embodiments, the blocks generated by a computing system cancontain rules and data for authorizing different types of actions and/orparties who can take action as described herein. In some embodiments,transaction and block forming rules may be part of the softwarealgorithm on each node. When a new block is being formed, any node onthe system can use the prior records in the blockchain to verify whetherthe requested action is authorized. For example, a block may contain apublic key associated with the user of a user device thatpurchased/acquired the physical object, this design that allows the userto show possession and/or transfer the digital license using a privatekey. Nodes may verify that the user is in possession of the one or morephysical objects and/or is authorized to transfer the one or morephysical objects based on prior events when a block containing thetransaction is being formed and/or verified. In some embodiments, rulesthemselves may be stored in the blockchain such that the rules are alsoresistant to tampering once created and hashed into a block. In someembodiments, the blockchain system may further include incentivefeatures for nodes that provide resources to form blocks for the chain.Nodes can compete to provide proof-of-work to form a new block, and thefirst successful node of a new block earns a reward.

Now referring to FIG. 8, an illustration of blockchain-basedtransactions according to some embodiments is shown. In someembodiments, the blockchain illustrated in FIG. 8 comprises a hash chainprotected by private/public key encryption. Transaction A 810 representsan event in a block of a blockchain showing that recipient 1 (e.g., anode creating a new block with transaction records associated withphysical objects, based on a received event). Transaction A 810 containsrecipient's 1 public key and recipient 0's signature for the transactionand a hash of a previous block. When recipient 1, central computingsystem transmits an alert including the public key and private key, toan independently operated domain, of the newly generated block storingthe transaction records, in a different independently operated domain,and the independently operated domain accesses the transaction record, ablock containing transaction B 820 is formed. The record of transactionB 820 comprises the public key of recipient 2, a hash of the previousblock, and recipient 1's signature for the transaction that is signedwith the recipient 1's private key 825 and verified using recipient 1'spublic key in transaction A 810. If recipient 2 (e.g., the node)transmits an alert including the public key and private key, to anindependently operated domain, of the newly generated block storing thetransaction records to recipient 3 (e.g., a different node), a blockcontaining transaction C 830 is formed. The record of transaction C 830comprises the public key of recipient 3, a hash of the previous block,and recipient 2's signature for the transaction that is signed byrecipient 2's private key 835 and verified using recipient 2's publickey from transaction B 820.

In some embodiments, when each event is created, the system may checkprevious events and the current recipient's private and public keysignature to determine whether the transaction is valid. In someembodiments, transactions are broadcasted in the peer-to-peer networkand each node on the system may verify that the transaction is validprior to adding the block containing the transaction to their copy ofthe blockchain. In some embodiments, nodes in the system may look forthe longest chain in the system to determine the most up-to-date eventto prevent the current recipient from double spending the asset. Thetransactions in FIG. 8 are shown as an example only. In someembodiments, a blockchain record and/or the software algorithm maycomprise any type of rules that regulate who and how the chain may beextended. In some embodiments, the rules in a blockchain may compriseclauses of a smart contract that is enforced by the peer-to-peernetwork.

Now referring to FIG. 9, a system according to some embodiments isshown. The exception handling system comprises a plurality of nodes 910communicating over a network 920. In some embodiments, the nodes 910 maycomprise a distributed blockchain server and/or a distributed timestampserver. Each node 910 in the system comprises a network interface 911, acontrol circuit 912, and a memory 913.

The control circuit 912 may comprise a processor, a microprocessor, andthe like and may be configured to execute computer-readable instructionsstored on a computer-readable storage memory 913. The computer-readablestorage memory may comprise volatile and/or non-volatile memory and havestored upon it a set of computer-readable instructions which, whenexecuted by the control circuit 912, causes the node 910 update theblockchain 914 stored in the memory 913 based on communications withother nodes 910 over the network 920. In some embodiments, the controlcircuit 912 may further be configured to extend the blockchain 914 byprocessing updates to form new blocks for the blockchain 914. Generally,each node may store a version of the blockchain 914, and together, mayform a distributed database. In some embodiments, each node 910 may beconfigured to perform one or more steps described with reference toFIGS. 7-9 herein.

The network interface 911 may comprise one or more network devicesconfigured to allow the control circuit to receive and transmitinformation via the network 920. In some embodiments, the networkinterface 911 may comprise one or more of a network adapter, a modem, arouter, a data port, a transceiver, and the like. The network 920 maycomprise a communication network configured to allow one or more nodes910 to exchange data. In some embodiments, the network 920 may compriseone or more of the Internet, a local area network, a private network, avirtual private network, a home network, a wired network, a wirelessnetwork, and the like. In some embodiments, the system does not includea central server and/or a trusted third party system. Each node in thesystem may enter and leave the network at any time.

With the system and processes shown, once a block is formed, the blockcannot be changed without redoing the work to satisfy census rulesthereby securing the block from tampering. A malicious attacker wouldneed to provide proof standard for each block subsequent to the onehe/she seeks to modify, race all other nodes and overtake the majorityof the system to affect change to an earlier record in the blockchain.

FIG. 10 is a block diagram of an example computing device forimplementing exemplary embodiments of the present disclosure.Embodiments of the computing device 1000 can implement embodiments ofthe system for resolving data discrepancies. For example, the computingdevice can be embodied as a portion of the central computing system,and/or a third party system. The computing device 1000 includes one ormore non-transitory computer-readable media for storing one or morecomputer-executable instructions or software for implementing exemplaryembodiments. The non-transitory computer-readable media may include, butare not limited to, one or more types of hardware memory, non-transitorytangible media (for example, one or more magnetic storage disks, one ormore optical disks, one or more flash drives, one or more solid statedisks), and the like. For example, memory 1006 included in the computingdevice 1000 may store computer-readable and computer-executableinstructions or software (e.g., applications 1030 such as the decisionengine 606) for implementing exemplary operations of the computingdevice 1000. The computing device 1000 also includes configurable and/orprogrammable processor 1002 and associated core(s) 1004, and optionally,one or more additional configurable and/or programmable processor(s)1002′ and associated core(s) 1004′ (for example, in the case of computersystems having multiple processors/cores), for executingcomputer-readable and computer-executable instructions or softwarestored in the memory 1006 and other programs for implementing exemplaryembodiments of the present disclosure. Processor 1002 and processor(s)1002′ may each be a single core processor or multiple core (1004 and1004′) processor. Either or both of processor 1002 and processor(s)1002′ may be configured to execute one or more of the instructionsdescribed in connection with computing device 1000.

Virtualization may be employed in the computing device 1000 so thatinfrastructure and resources in the computing device 1000 may be shareddynamically. A virtual machine 1012 may be provided to handle a processrunning on multiple processors so that the process appears to be usingonly one computing resource rather than multiple computing resources.Multiple virtual machines may also be used with one processor.

Memory 1006 may include a computer system memory or random accessmemory, such as DRAM, SRAM, EDO RAM, and the like. Memory 1006 mayinclude other types of memory as well, or combinations thereof. A usermay interact with the computing device 1000 through a visual displaydevice 1014, such as a computer monitor, which may display one or moregraphical user interfaces 1016, multi touch interface 1020 and apointing device 1018.

The computing device 1000 may also include one or more storage devices1026, such as a hard-drive, CD-ROM, or other computer-readable media,for storing data and computer-readable instructions and/or software thatimplement exemplary embodiments of the present disclosure (e.g.,applications such as the decision engine 606). For example, exemplarystorage device 1026 can include one or more databases 1028 for storinginformation associated with physical objects and events associated withthe physical objects. The databases 1028 may be updated manually orautomatically at any suitable time to add, delete, and/or update one ormore data items in the databases.

The computing device 1000 can include a network interface 1008configured to interface via one or more network devices 1024 with one ormore networks, for example, Local Area Network (LAN), Wide Area Network(WAN) or the Internet through a variety of connections including, butnot limited to, standard telephone lines, LAN or WAN links (for example,802.11, T1, T3, 56 kb, X.25), broadband connections (for example, ISDN,Frame Relay, ATM), wireless connections, controller area network (CAN),or some combination of any or all of the above. In exemplaryembodiments, the central computing system can include one or moreantennas 1022 to facilitate wireless communication (e.g., via thenetwork interface) between the computing device 1000 and a networkand/or between the computing device 1000 and other computing devices.The network interface 1008 may include a built-in network adapter,network interface card, PCMCIA network card, card bus network adapter,wireless network adapter, USB network adapter, modem or any other devicesuitable for interfacing the computing device 1000 to any type ofnetwork capable of communication and performing the operations describedherein.

The computing device 1000 may run any operating system 1010, such as anyof the versions of the Microsoft® Windows® operating systems, thedifferent releases of the Unix and Linux operating systems, any versionof the MacOS® for Macintosh computers, any embedded operating system,any real-time operating system, any open source operating system, anyproprietary operating system, or any other operating system capable ofrunning on the computing device 1000 and performing the operationsdescribed herein. In exemplary embodiments, the operating system 1010may be run in native mode or emulated mode. In an exemplary embodiment,the operating system 1010 may be run on one or more cloud machineinstances.

FIG. 11 is a flowchart illustrating an exemplary process of anembodiment of a nested blockchain system in accordance with the presentdisclosure. The nested blockchain system can include distributed nodesin a network. In operation 1100, a node is configured to generate amaster cryptographically verifiable distributed ledger represented by asequence of blocks. Each block contains one or more transactions recordsand each subsequent block containing a hash value associated with theprevious block. In operation 1102, the node generates a first block inthe master cryptographically verifiable ledger for a first event inresponse to receipt of the first event from a third party system. Inoperation 1104, the node executes code included in an associated blockof the master cryptographically verifiable ledger to verify that thefirst event corresponds with a first set of one or more conditions. Inoperation 1106, in response to verification of the first event, the nodespawns a first sub cryptographically verifiable ledger represented by afirst genesis block containing a hash value referencing the first blockgenerated in the master cryptographically verifiable ledger. Inoperation 1108 the node generates a second block in the first subcryptographically verifiable ledger for a second event in response toreceipt of a second event from the third party system. In operation1110, the node executes code included in the first genesis block toverify that the second event corresponds with a second set of one ormore conditions. In operation 1112, in response to the verification ofthe second event, the node purges the first sub cryptographicallyverifiable ledger.

In describing exemplary embodiments, specific terminology is used forthe sake of clarity. For purposes of description, each specific term isintended to at least include all technical and functional equivalentsthat operate in a similar manner to accomplish a similar purpose.Additionally, in some instances where a particular exemplary embodimentincludes a multiple system elements, device components or method steps,those elements, components or steps may be replaced with a singleelement, component or step. Likewise, a single element, component orstep may be replaced with multiple elements, components or steps thatserve the same purpose. Moreover, while exemplary embodiments have beenshown and described with references to particular embodiments thereof,those of ordinary skill in the art will understand that varioussubstitutions and alterations in form and detail may be made thereinwithout departing from the scope of the present disclosure. Furtherstill, other aspects, functions and advantages are also within the scopeof the present disclosure.

Exemplary flowcharts are provided herein for illustrative purposes andare non-limiting examples of methods. One of ordinary skill in the artwill recognize that exemplary methods may include more or fewer stepsthan those illustrated in the exemplary flowcharts, and that the stepsin the exemplary flowcharts may be performed in a different order thanthe order shown in the illustrative flowcharts.

1. A distributed database management system, the system comprising: aplurality of distributed nodes in a network; one or more of theplurality of nodes configured to: generate a master cryptographicallyverifiable distributed ledger represented by a sequence of blocks, eachblock containing one or more transactions records and each subsequentblock containing a hash value associated with the previous block;generate a first block in the master cryptographically verifiable ledgerfor a first event in response to receipt of the first event from a thirdparty system; execute code included in an associated block of the mastercryptographically verifiable ledger to verify that the first eventcorresponds with a first set of one or more conditions; in response toverification of the first event, spawn a first sub cryptographicallyverifiable ledger represented by a first genesis block containing a hashvalue referencing the first block generated in the mastercryptographically verifiable ledger; generate a second block in thefirst sub cryptographically verifiable ledger for a second event inresponse to receipt of a second event from the third party system;execute code included in the first genesis block to verify that thesecond event corresponds with a second set of one or more conditions;and in response to the verification of the second event, purge the firstsub cryptographically verifiable ledger.
 2. The system of claim 1,wherein the one or more of the plurality of nodes is programmed toreceive a third event.
 3. The system of claim 2, wherein the one or moreof the plurality of nodes is programmed to: generate a third block inthe master cryptographically verifiable ledger containing transactionrecords of the third event; execute code included in the third block toverify the third event corresponds with a third set of one or moreconditions; in response to verification of the third event, spawn asecond sub cryptographically verifiable ledger represented by a secondgenesis block containing a hash value associated with the third blockgenerated in the master cryptographically verifiable ledger, associatedwith the third event.
 4. The system of claim 3, wherein the one or moreof the plurality of nodes is programmed to receive a fourth event. 5.The system of claim 4, wherein the one or more of the plurality of nodesis programmed to generate a fourth block in the second subcryptographically verifiable ledger containing transaction recordsassociated with the fourth event.
 6. The system of claim 5, wherein theone or more of the plurality of nodes is programmed to purge the secondsub cryptographically verifiable ledger after a specified amount of timeafter receiving the fourth event.
 7. The system of claim 1, wherein thefirst event is associated with the request of a delivery of a physicalobject, the second event is associated with the completion of thedelivery of the physical object.
 8. The system of claim 1, wherein theone or more transaction records include one or more of a quantity of theat least one physical object, a name of the at least one physicalobject, a type of the at least one physical object and a size of the atleast one physical object.
 9. The system of claim 1, wherein the thirdparty system is one or more of a: mobile device, a terminal or acomputing device.
 10. The system of claim 9, wherein the terminal isdisposed in a facility.
 11. A distributed database management method,the method comprising: generating, via one or more of a plurality ofdistributed nodes in a network, a master cryptographically verifiabledistributed ledger represented by a sequence of blocks, each blockcontaining one or more transactions records and each subsequent blockcontaining a hash value associated with the previous block; generating,via the one or more of the plurality of nodes, a first block in themaster cryptographically verifiable ledger for a first event in responseto receipt of the first event from a third party system; executing, viathe one or more of the plurality of nodes, code included in anassociated block of the master cryptographically verifiable ledger toverify that the first event corresponds with a first set of one or moreconditions; in response to verification of the first event, spawning,via the one or more of the plurality of nodes, a first subcryptographically verifiable ledger represented by a first genesis blockcontaining a hash value referencing the first block generated in themaster cryptographically verifiable ledger; generating, via the one ormore of the plurality of nodes, a second block in the first subcryptographically verifiable ledger for a second event in response toreceipt of a second event from the third party system; executing, viathe one or more of the plurality of nodes, code included in the firstgenesis block to verify that the second event corresponds with a secondset of one or more conditions; and in response to the verification ofthe second event, purging, via the one or more of the plurality ofnodes, the first sub cryptographically verifiable ledger.
 12. The methodof claim 11, further comprising receiving, via the one or more of theplurality of nodes, a third event.
 13. The method of claim 12, furthercomprising: generating, via the one or more of the plurality of nodes, athird block in the master cryptographically verifiable ledger containingtransaction records of the third event; executing, via the one or moreof the plurality of nodes, code included in the third block to verifythe third event corresponds with a third set of one or more conditions;in response to verification of the third event, spawning, via the one ormore of the plurality of nodes, a second sub cryptographicallyverifiable ledger represented by a second genesis block containing ahash value associated with the third block generated in the mastercryptographically verifiable ledger, associated with the third event.14. The method of claim 13, further comprising receiving, via the one ormore of the plurality of nodes, a fourth event.
 15. The method of claim14, further comprising generating, via the one or more of the pluralityof nodes, a fourth block in the second sub cryptographically verifiableledger containing transaction records associated with the fourth event.16. The method of claim 15, purging, via the one or more of theplurality of nodes, the second sub cryptographically verifiable ledgerafter a specified amount of time after receiving the fourth event. 17.The method of claim 11, wherein the first event is associated with therequest of a delivery of a physical object, the second event isassociated with the completion of the delivery of the physical object.18. The method of claim 11, wherein the one or more transaction recordsinclude one or more of a quantity of the at least one physical object, aname of the at least one physical object, a type of the at least onephysical object and a size of the at least one physical object.
 19. Themethod of claim 11, wherein the third party system is one or more of a:mobile device, a terminal or a computing device.
 20. The method of claim9, wherein the terminal is disposed in a facility.